proto/initia/gov/v1/gov.proto (1)

Line range hint 145-153: Enhance documentation for the TallyResult message.

While the structure is well-defined, consider adding more detailed documentation to clarify:

1. The relationship between total_staking_power, total_vesting_power, and the values in v1_tally_result
2. The significance of tally_height and when it gets updated

Add documentation comments like this:

 // TallyResult defines the result of a tally.
+// It extends the cosmos-sdk TallyResult by separately tracking staking and vesting power,
+// while maintaining compatibility with the original format.
 message TallyResult {
+  // tally_height represents the block height at which the tally was computed
   uint64 tally_height = 1;
+  // total_staking_power represents the total voting power from staking at tally_height
   string total_staking_power = 2 [(cosmos_proto.scalar) = "cosmos.Int"];
+  // total_vesting_power represents the total voting power from vesting at tally_height
   string total_vesting_power = 3 [(cosmos_proto.scalar) = "cosmos.Int"];

x/ibc/nft-transfer/keeper/relay.go (1)

Line range hint 48-63: Consider using optional memo parameter

The function now passes an empty string for memo by default. Consider making this parameter optional or using a pointer/Option type to better represent the absence of a memo.

-func (k Keeper) SendNftTransfer(
+func (k Keeper) SendNftTransfer(
 	ctx sdk.Context,
 	sourcePort,
 	sourceChannel string,
 	classId string,
 	tokenIds []string,
 	sender sdk.AccAddress,
 	receiver string,
 	timeoutHeight clienttypes.Height,
 	timeoutTimestamp uint64,
+	memo *string,
 ) error {
+	memoStr := ""
+	if memo != nil {
+		memoStr = *memo
+	}
 	_, err := k.sendNftTransfer(
 		ctx, sourcePort, sourceChannel,
 		classId, tokenIds, sender, receiver,
 		timeoutHeight, timeoutTimestamp,
-		"",
+		memoStr,
 	)
 	return err
 }

api/ibc/applications/perm/v1/types.pulsar.go (1)

Migration from gogoproto is incomplete

The verification reveals an inconsistency in the protobuf implementation:

• While types.pulsar.go has removed the gogoproto import, the corresponding proto/ibc/applications/perm/v1/types.proto and other .proto files still contain gogoproto imports
• This suggests an incomplete migration where generated .pulsar.go files have moved away from gogoproto, but the source .proto files haven't been updated accordingly

🔗 Analysis chain

Line range hint 1-12: Verify the impact of removing gogoproto dependency

The removal of gogoproto import suggests a migration from gogo protobuf. This change should be consistent across all generated protobuf files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining gogoproto dependencies
# Test: Search for gogoproto imports. Expect: No remaining imports.
rg -l 'github.com/cosmos/gogoproto/gogoproto'

# Test: Search for gogo.proto imports in .proto files. Expect: No remaining imports.
rg -l 'gogoproto/gogo.proto' --type proto

Length of output: 2547

---

Script:

#!/bin/bash
# Let's check for .proto files first to ensure we're searching the right file type
fd '\.proto$'

# Then search for gogoproto imports in .proto files
fd '\.proto$' --exec grep -l "gogoproto/gogo.proto" {}

# Let's also check the specific file we're reviewing for any remaining gogoproto annotations
cat api/ibc/applications/perm/v1/types.pulsar.go | grep -A 5 -B 5 "gogo"

# Check other .pulsar.go files in the same directory for consistency
ls api/ibc/applications/perm/v1/*.pulsar.go

Length of output: 3918

api/initia/gov/v1/gov.pulsar.go (1)

Line range hint 5165-5174: Clarify the necessity of both custom fields and V1TallyResult

The TallyResult struct includes custom fields (TallyHeight, TotalStakingPower, TotalVestingPower) as well as an embedded V1TallyResult from the cosmos-sdk, which may contain overlapping data. Consider whether including both sets of fields is necessary or if it introduces redundancy. Simplifying the struct could improve maintainability.

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify that `TotalStakingPower` and `TotalVestingPower` are consistently declared and used.

# Search for declarations of TotalStakingPower and TotalVestingPower
ast-grep --pattern $'
type $_ struct {
  $$$
  TotalStakingPower $_
  TotalVestingPower $_
  $$$
}'

#!/bin/bash
# Search for usage of TotalStakingPower and TotalVestingPower in function implementations
rg -A 5 "TotalStakingPower|TotalVestingPower" --type go

#!/bin/bash
# Search for math operations or conversions involving these fields
rg -B 2 -A 2 "\.String\(\)|\.Add\(|\.IsZero\(|\.Parse" x/gov/keeper/

Makefile (1)

Line range hint 159-174: Consider documenting the protobuf generation workflow.

The protobuf generation system is well-structured with clear separation between swagger and pulsar generation. Consider adding documentation in the repository (e.g., in docs/ or CONTRIBUTING.md) to explain:

1. The purpose and output of each generator
2. The relationship between proto files and generated artifacts
3. When developers need to run these generators

Configuration used: CodeRabbit UI
Review profile: CHILL